Template talk:SR enemy experience
Few pointers Firstly, thanks for making this template - publishing EXP values has been due for a long time. Some things I'd like to say... * Should we place such a table in the corresponding stages too? Jap Wiki arranges it by stages, and it can be useful for finding out the best time to attempt a stage. * I wish we could colour it like the Japanese do, but... it's too much of a hassle isn't it. * Lastly, we may want to add in some code that writes the message "and above" for lvl_end, and "and below" for level_start. This way, for each experience table we will st--Justme2 21:34, 26 December 2008 (UTC)art with "Level X and below: 1 EXP" and end the table with "Level Y and above: 1 EXP". --bewnt 01:38, 26 December 2008 (UTC) :Well, ... :* The original plan was in fact to create a flexible table with up to five or six colums for enemies, including their pictures, above each colum. But it took some time to even get the expressions in Template:SR_enemy_experience/line working. But now that I think of it, it shouldn't be very hard to extend it to more than one EXP colum. :* Colors are no problem. It's just a little extra work, and figuring out, which colors we want to use, or between which colors we want to blend. I just have to do it right, to make it possible to change them with the new skin, which I'm currently developing. :* Hmm, I thought you show 3 or 4 times the 1 EXP at each end, and the user would understand it. But I think I can do this with the above/below text. But there are some special cases, for example you don't show the "below" if "start lvl" is 1. And it is possible for the user to cut of the area with 1 EXP, by setting a too narrow start lvl and end lvl. In this case the "and above/below" text would be wrong. I could either remove the text in this case or display a warning. :* Another thing: I thought about reducing the font size, because the table is really big. And with more colums it will even get bigger. Also if I do the thing with the pictures we should have a slim (or more vertical) version of Image:Orange Boss Skull Dragon.png and Image:Red Big Skull Dragon.png. : --Justme2 12:25, 26 December 2008 (UTC) :: I wish to shorten the two headers to "LVL" and "EXP" - that way, the table will be slimmer and easier to read. However I'm worried that new readers may confuse "lvl" for enemy level (which doesn't exist) and "EXP" for the current EXP players have. Can we link the header to the template page so that newbies will know how to read the table? --bewnt 12:54, 26 December 2008 (UTC) ::: I extended it to 6 colums. This made some trouble with additional line break suddenly appearing within the table cells, and I couldn't really find out from where they were coming, but finally I was able to remove them. Colors are also working now, but I have to choose other colors, of course. And I have to prevent the border from changing, too. An example can be seen on Dan-Ball_Wiki:Sandbox#Test_SR_enemy_experience_template. Images for the enemies are still missing. --Justme2 21:34, 26 December 2008 (UTC) Long loading time I normally use FF, and when trying to load Talk:Enemy, it attempts to load before coming up with a "connection interrupted" message. I think the template takes too long to load: I tried removing some of the template tables on the Talk:Enemy page and the page was able to load. Is there any way to reduce load time? --bewnt 03:05, 2 January 2009 (UTC) : With FF3 I don't get a timeout. The page starts loading after 16 seconds and complete transmission and rendering is finished after 20 seconds. This corresponds to my experience with Opera. : I thought this only applies to the first call after a change to the template, because the server cache of the talk page is invalid now. But it seems this isn't true. You need the 20 seconds for every call (unless you don't use your browser cache). This is a little bit too much, because this means we have between 1 or 2 seconds for the generation of such a table. : One way to reduce the traffic is to remove all CSS stuff from the table. We only use one (or only a few) class names for it and try to do all skinning in MediaWiki:Common.css. But I first have to test if this file is really included for all skins and themes. I think this would reduce the HTML-code of the table by maybe 80%. But I somehow doubt that this generates a great performance benefit. : Also we can use "subst: witht the template". But I think this only includes the template code into the article. I don't believe that all those #if and #ifexp and #switch get preexecuted and removed. Also the subtemplate does not get unrolled. And we have to manually insert the template call every time we changed the template in all articles completly new. And we lose the template call with the original paramter values (if we don't make a commented out copy of it), because it gets replaced with the table. If only the template calls are causing the performance problem, using subst might help. But I think the #if, #ifexp and #switch are more likely a problem. : I think we should first try, if the MediaWiki:Common.css is working for all skins and if this is true we should do it (no matter whether it helps or not, because it reduces code size). If the performance is still bad we could show it to the helpers in the IRC and ask them about some hints what might cause the performance problems, and how we could fix them. --Justme2 15:58, 2 January 2009 (UTC) :: Moving the CSS stuff has simplified the template. As expected this didn't bring us some performace back. I have asked in the IRC, how we could improve it and M.mendel‎ is currently trying to find a solution, probably with a "pretty radical redesign" of the template. In advance a big thanks to him, even for only trying! --Justme2 01:51, 19 January 2009 (UTC) ::: Mendel has really done a very good job! ::: He found a way which will bring us a massive speed bonus. I currently estimate the generation of all tables on Talk:Enemy with about 3 or 4 seconds or maybe even less, which means our stage pages will load fast enough. This is important because I believe a lot of people use the world map navigation to find stages and enemies. Although the template will have douzends of subpages (for up to six enemies 3+7+6*4=34 pages), and the code is a little bit hard to understand the first time you look at it, it has a very clean code design. See w:c:guildwars:User:M.mendel/Templates/danball if you are interested in the code, and if you want I can explain how it works. Restrictions of the template are: It can have only a maximum number of enemy colums (for example 6, which is the same as now) and it only can handle enemies with a certain height of the peak value (for example 100,150,200,300,500,800 and 1000). But for each enemy with a new peak height you only have to doublicate and adjust one simple page (everybody could do this with some documentation). To finish the template for our purpose we only have to add the table header with the images (this is no problem) and we have to find an efficient way for the "+" and "-" marker at the levels. I'll ask him about this, in the evening. Huge thanks to Mendel! --Justme2 12:52, 20 January 2009 (UTC) ::: I forgot one thing: If we would do the table layout horizontal, instead of vertical, we would could be increadibly fast. The colums would represent the different player levels. And the rows represent the different enememies. Maybe this is even a better solution, because the right border has the stage nav and often also an advertisement. But it might also be a little bit strage, that the exp numbers of one enemy are next to each other and not below each other. What do you think of this? --Justme2 13:17, 20 January 2009 (UTC) :::: I must agree that when placed horizontally, it won't be easy to read. I believe vertical is still easier, though it would be more pain to code if I'm not mistaken. Kudos to you for making the effort to contact an expert, as well as Mendel for taking time off to help us. --bewnt 13:54, 20 January 2009 (UTC) ::::: Example for a horizontal layout: w:c:guildwars:Energy Boon --Justme2 00:02, 21 January 2009 (UTC) :::::: It is easier to compare values across different enemies if the table is laid vertically. For the table in the above link, there is no need to compare values between rows. It is also very easy to create confusion with numbers squished together on the same row, especially since our EXP numbers usually involve many zeroes. Lastly, because the font height is consistent, the EXP numbers are very neat when arranged vertically. --bewnt 12:09, 21 January 2009 (UTC) Highlighted Borders Gah, the problem of only two borders out of four appearing is cropping up again. When I tried to implement it, the exact same thing happened. Must be the CSS, though I don't understand a thing in there. --bewnt 12:03, 19 January 2009 (UTC) : I already noticed it, an I'm working on a fix. The problem is the collapsing border model of CSS and the border conflict resolution http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution. Both neighbouring cells have a border, so the problem is, which border is more important. According to the standard the rule is: :*First, the more expressed style goes first. (double' over 'solid' over 'dashed' over 'dotted) :*If this doesn't decided it, then the layering is important (cell border over row border over colum border over table border) :*And finally (and that's what's causing our problems) border of cells which are more to the left and top go over other borders. : I'm currently trying to fix this by only setting top and left border in a cell. But I have problem to verify my solution because I think I have again some caching problems. (The european wikia servers had some problems with cache updates yesterday.) --Justme2 12:50, 19 January 2009 (UTC) :: OK, it works for IE and Mozilla, but not for Opera. I don't know why, but he is not following the standard and only the top and left color is white. This is even quite the opposite to the "top and left first" rule. I could bet this is only because the whole page is so buggy, that he goes into the "quirk" mode. I'll try it, if it works with a valid page, if I have time, but that doesn't help us. --Justme2 13:30, 19 January 2009 (UTC) :: I guess the Opera users (which includes myself) might have to live with that. This is OK for me, because if the error only leads to some minor display problems, and if there is no easy workaround, I usually don't make exceptions for browsers which don't follow the standards (but in most cases this hits the IE, and not FF or Opera). :: Another solution is to highlight the text instead of the cell borders. I have done this now by using pure white as text color. What do you think of it? A blue-ish white is also possible, or we can make the text bold. Or, as already said, we can keep the borders. --Justme2 14:00, 19 January 2009 (UTC) ::: It is indeed weird: as you said, bugs usually hit IE, not FF/Opera, much less one of them only. I do not encourage bold, because it increases the text size if I'm not wrong. The current white seems like the best option that works across all browsers. I wonder if the border issue can be solved by using a heavy border for the peak cells? --bewnt 14:11, 19 January 2009 (UTC) :::: It works perfectly with a 2px border (because 2px > 1px, and therefore priority), but it looks terrible. I also tried using a 1.5px border or 1.1px border, but this results in a 1px border for opera and he finally concludes "1.5px = 1px, its not a larger, therefore no priority" which is somehow wrong. I try the double border now. The other possibility is to use the dotted or dashed border for the normal grid. --Justme2 14:55, 19 January 2009 (UTC) ::::: The double border completly failed. Opera and IE are displaying a normal solid border, FF displays nothing (probably it is showing the pixels in between the double line and not displaying the lines somehow. The dotted line works for all browsers but it doesn't look that good. I also could handle the whole thing on template level, and if the cell in the neighbour color is a peak, I handle this, but this makes the whole template (with it's low performance) even more complicated. --Justme2 15:36, 19 January 2009 (UTC) Implementation Thanks to Mendel and me2 for their hard work, this template has now been optimised. I don't see any problems with it, except for the dotted lines (which can't be helped). Like Stick Ranger, I feel that it's time that this template got out of beta testing. Does anyone disagree? If not, where should we place these templates: on stage pages, enemy articles or both? --bewnt 13:49, 23 January 2009 (UTC) : Uhh, no it has not been optimized. The only thing is, that the CSS has been improved. But this didn't bring some speed. Or is it faster for you??? : But now we know how to do it right. Adopting the new code shouldn't be the problem. But unfortunately I'm now going skiing till 2.2.09. Maybe I can do it tomorrow, but I don't know if I have enough time, because I have to create a lot of subpages. Mendel also wanted to try a different version, that's why I havn't copied his work. I'll ask him about that. : Well, you can integrate the current "old" version. I'll expect, that it slows down the stage pages by about 1 or 2 seconds. But I think we can live with this until I have time to implement Mendel's speedy version. Parameters won't change for the new version (at least not much). --Justme2 14:55, 23 January 2009 (UTC) :: I'll prefer it if the work's done. For now we'll redirect users to Talk:Enemy when queried about EXP values and enemy levels. As for speed, what took 20 seconds in the past (and caused interrupted connections) now takes 6-7 seconds: a drastic improvement if you ask me. Have fun during your ski trip! --bewnt 15:11, 23 January 2009 (UTC) ::: I've implemented the new version and messured some performance values, based on five test runs for each: ::: Well, looks better than before ... --Justme2 21:09, 5 February 2009 (UTC) About the level cap Can we add the lv cap ( 71 / 10+hightest lv of the enemy in the unlocked stages) in this template??? Yathimc 15:02, February 23, 2012 (UTC) The Working Principle The Working Principle of this template is odd and low efficient (we have to create a sub-template when there is a new enemy with new EXP), I think we should rewrite it from scratch (although it is hard). Yathimc (talk) 03:04, December 5, 2012 (UTC) ...Challenge Denied. Too difficult. (at least for me)Ivan247Talk Page 05:41, December 5, 2012 (UTC) SOSAD Yathimc (talk) 05:57, December 5, 2012 (UTC)